Complete Linux

home *** CD-ROM | disk | FTP | other *** search

/ Complete Linux / Complete Linux.iso / sls / readme < prev next >

Wrap

Text File | 1994-05-01 | 23.8 KB | 511 lines

SLS 1.05 RELEASE: ----------------- ********************************************************************** Please Note: because of reports that some are having problems with the modular boot kernel, SLS has fallen back to using the standard Linux 1.0 kernel. The kernel source is now also the standard 1.0. the patch file b7/lxdif.tgz can be applied for the modular kernel. Be advised that this patch is huge (almost 1.6Meg). The current modular bootdisk a1.3 is available in the Modules sub-directory. There is also a test a1.3 boot disk in the Test sub-directory, that is in testing by those who reported problems. It's accompanying README should be consulted first. If you have any problems, please direct correspondance to: pmacdona@sanjuan.uvic.ca ********************************************************************** Announcing, the official of the release of SLS 1.05, the Softlanding (Modularized) Linux System. It is a joint announcement of the release of the SLS 1.05, the CD and the kernel modularization patches. Modularization of the kernel is aimed squarely at reducing, and eventually eliminating the requirements for recompiling the kernel, either for changing/modifying device drivers or for dynamic access to infrequently required drivers. More importantly, perhaps, the efforts of individual working groups need no longer affect the development of the kernel proper. In fact, a binary release of the official kernel should now be possible. SLS 1.05 is available for ftp'ing from tsx-11.mit.edu. Additionally, the CD version or floppy or tape distributions can be obtained from Softlanding Software (see below for more info). The CD will begin shipping shortly so all Quarterly subscribers should be receiving their next installment in the next few weeks. SLS 1.05 FEATURES: ------------------ - The Linux kernel 1.0, fully modularized by Softlanding (totalling 63 modules). - Nearly everything is loadable (devices, fs's, network, math, etc) - Many extra loadable modules included (IFS, Double FS, IPX, CD, ...). - A powerful, flexible menu shell (Mesh) written for SLS system admin. - A massive shift to Tcl and Tk apps (like Picasso and XTeXShell). - Idraw and Doc (Interviews) are gone, so is clisp. - Elvis has been supersceded by VIM (which has help and no refresh bug). - Addition of two new shells: tcsh and pdksh. Added Pine as well as elm. - man pages are not preformatted, so as to support Tkman (and printing). - XFree86 2.0, with modified Servers link kit to allow compileless link. - Most binaries updated and libreadline in ftp, bash, the wish shells... - migration to linux-utils 1.5, with modifications to add shadow support. - adoption of /sbin, for that leaner, cleaner /etc look (see below). - Non-destructive installation option (over existing ext2 fs partitions). - Holes are now automatically compressed on install, for "ALL" files. - Network/CD/HD installs now try to do the mount, "before" doing a mke2fs. - Unavoidably, one disk has been added (to 'b') giving 31-5.25 or 26-3.5. CDROM FEATURES: ---------------- The CDROM has the following additional features: - no binaries are located in /etc. - preceding means SLS runs from CD in 400K+ ramdisk (for /etc, /tmp, ...) - Linux source tree with all .o's intact for quick driver mods. - XFree86 2.1 in addition to 2.0 - Contains Andrew, Interviews, Object Builder, etc. - Includes mainstream packages such as mosaic, gopher, archie, etc. - Contains both X and non-X versions of most programs. - A large repository of Tcl/Tk code (most all that is available?). - Contains about twice the source code of the previous release (compressed). Installation options include: - Install directly from CDROM - Install from CD, over the network (3 1/2 boot only) - Install from harddrive, over the network (3 1/2 boot only) - Copy the /install packages to a DOS hard drive for installation - Copy the /install packages to a DOS floppies (both 3.5 and 5.25) - tar the /install packages to Tape for installation Operational modes for the CD include: 1) run from CD, with no writable file space 2) run from CD, with a small (600K+) ramdisk 3) run from CD, with a partition mounted on /local 4) run with installation ramdisk as root and mounting CD on /mnt 5) run with mini install (~15 Meg) and mounting CD on /mnt 6) run with mini install and NFS mounting remote CD on /mnt 7) run with mini install and NFS mounting remote SLS on /mnt Note that options 1), 2) and 4) can be used on machines with no harddrive. Also, with the introduction of the loadable ramdisk, option 1) can be converted into option 2) anytime after bootup, by running "MakeRamDisk". Running from CD, even on diskless machines, is now very practical, because the directories that contain config files are now all contained on a single mount point to either a ramdisk, floppy or regular disk. Unlike the previous SLS CD's, the sources have grown in volume to the point where they must now be distributed as compressed tar archives, in order to fit them all onto the CDROM. "updatedb" has been run on the CD, so any file on the CD can be located in seconds using the "locate" command. From the hard drive you can locate any file containing PATTERN with: locate -d /a/cd/usr/lib/find.codes PATTERN Man pages are provided in both formatted and unformatted format. 1.05 SYNOPSIS: -------------- The primary feature of this release is Linux 1.0 modified to convert nearly all Linux devices and facilities into loadable modules. It is hoped that eventually this will cause the number of kernel patches to diminish, and the current kernel to be split into two pieces: kernel proper and kernel modules. Perhaps an API can even be evolved to reduce dependancies on kernel data structures. Following is a condensed list of the 63 or so modules that have resulted from the SLS kernel modularization: at1700 atixlmouse atp ax25 binfmt_coff binfmt_elf busmouse cdu31a cdu535 d_link dble dscsi dsd dsg dsr dst el1 el3 el7 el9 ext ext2 fdomain floppy g_NCR5380 hp hpfs_fs ifs inet ipx isofs lance lmscd lp math mcd minix msbusmouse msdos ne net_dev nfs panasonic pas16 proc procdev psaux quota ramdisk sbpcd seagate slippp sound sysv t128 tpqic02 ultra ultrastor unix wd wd7000 xd xiafs Central to the feasibility of a modularized kernel is our bootstrap loader which allows bundling modules up into a kernel image permitting even disk drivers to be modularized. This bootloader was implemented as an extension to insmod. There is now only one kernel image: the one on the bootdisk. The kernel on the 3 1/2 is identical to the 5 1/4 except that it bootloads the network and NFS code. But since the Net code is loaded, the only difference is that you have to manually load the network after bootup, if you do an installation from 5 1/4's. Likewise, the 3 1/2 zImage is identical to the 5 1/4 if it is started with the lilo option "exc=unix,net_dev" (see below for details). COPYRIGHT: ---------- As with virtual consoles, ptys, shared libs and other Softlanding contributions, these kernel patches are covered by the same GPL copyright as Linux. Please refer to /usr/src/linux/COPYING for details. Programs/packages in SLS are copyrighted by their respective authors. In all cases, to the best of our knowledge, "we think" none of these restrict commercial redistribution, provided you observe GNU like redistribution policies. SLS system admin and system install specifics, other than the above, are copyright Softlanding Software, whose copyright is the same as GPL, except that you can not rename SLS (say by creating a new distribution using SLS sysadm) without permission. Redistribution, for any other purpose whatsoever is hereby granted. LOADABLE DEVICES: ----------------- Virtually everything that is not part of the intrinsic kernel logic in SLS has now been made loadable. As well as regular devices, such as CD's, parallel ports and mice, all of file systems are now loadable. Ditto for networking code. The unix domain sockets are loadable (perhaps only useful for development). Individual protocols such as IPX and AX25 are now also loadable. So also is the sound code, the Elf and Coff binary formats and the math emulator. The ramdisk is also loadable and unloadable, and so can have it's size set at runtime. Even things you might not consider candidates for loading, like quotas for example, are. So you must load the quota's module first, in order to use quotas. The SCSI devices have also been made loadable, but since SCSI has both low and high level drivers, the concept of composite modules is introduced. Composite modules simply permit a module to add symbols to the kernel symbols list that is exported for module linking. In the case of SCSI, first the generic SCSI code is loaded. Then the low-level (board/ controller) drivers are loaded. Lastly are the high-level (tape/disk/CD) drivers. The last high-level driver loaded is passed an argument telling it that it is last, and so to initialize the scsi subsystem. Failure to detect a board, causes all scsi modules to be deleted. BOOTTIME MODULE LOADING: ------------------------ The other major piece to the puzzle was a bootstrap loader for linux modules, to allows modules to be bundled with a boot image. In essence, the bootstrap loader piggybacks a collection of modules onto the end of the kernel image before it is compressed. At boot time, the modules are initialized and autodetected as usual. In all cases, if prerequisites are not detected at boottime, the module is unloaded, freeing it's memory and resources. For math.o for example, this means that autodetection of a coprocessor automatically unloads the math emulation software. A side benefit of boottime loading is that the call to xxx_setup() does not Result in a kernel patch to init/main.c, because the module loader automatically senses the presence of the xxx_setup() routine and calls it for you with any commandline arguments from the lilo prompt. POSTBOOT MODULE LOADING: ------------------------ Some drivers, such as disk controller code, need to be loaded at boottime, but others, such as Network code can be loaded after bootup. To have the modules loaded automatically for you, you could just do something like the following: move or copy the desired modules from the source tree, or from /install/modules/src to /install/modules/ The following lines, which have been added to the top of /etc/rc.local will auto load them for you. if [ -d /install/modules -a -d /proc/dev ]; then (cd /install/modules; for i in *.o; do insmod $i; done ) fi Interestingly, object files that are loadable modules are no different than ordinary .o's in that they can still be statically linked. When using "make config" on the Linux kernel, there are now four options: include, exclude, loadable and boot-loadable. You can identify loadable modules in "make config" by a "*" in the first column. Selecting 'l' instead of 'y' or 'n' makes the module loadable. Selecting 'm' cause the module to be loaded at boottime before the root fs is mounted. Implementation-wise, loadable modules use the same .o files that the kernel links in. There is no need to recompile the module if you decide to statically link it, rather than load it. See below for more details. PROC/DEV: --------- One other thing that this release adds is optional support for /proc/dev. The purpose of /proc/dev is to allow the kernel to report which devices it presently considers valid. Currently, the device reporting is not yet very accurate, so it is not compiled in by default, but eventually this feature could be used by configuration software, in setting up the system, and in particular, the /dev directory as in AIX. However, the main benefit lies in the dynamic allocation of major or minor device numbers, of which the former are in short supply. A dynamic scheme could have the module loader create the requisite /dev entries. This would also help developers avoid dev collisions. MODULE ARGUMENTS: ----------------- The insmod.c code has also been modified to allow passing arguments to modules using the -a option. This is used by such modules as ramdisk.o, to allow setting the ramdisk size, so a ramdisk can be created and destroyed at any time. Currently, the size can be changed without rebooting by unloading and reloading with a different value. 4096 (4Meg) is the current maximum. There is also a -f option, to force loading even if the version of the module does not match the kernel version. BOOTSTRAP MODULES: ------------------ It became necessary to modify the compressed-image bootup code, because there was no longer room in the < 640K area for the compressed kernel and the gzip code to run. So now the kernel is moved to just below the 2Meg mark before decompression, and the uncompressing data chases the compressed data boundary. CONFIGURATION VIA LILO: ----------------------- A few simple options are currently supported with lilo, to control which the handling of bootstrap loaded modules. The first, the exclude option causes the named modules to be *not* loaded or autodetected. exc=module1,module2,... causes the modules to be disabled and discarded. Since composite module members are checked at load time to ensure that dependant modules are already loaded, you can disable whole hierarchies of modules with a single statement. For example to disable all scsi and all network devices in one fell swoop use exc=net_dev,dscsi On the other hand, you can specify just the modules to include with: inc=module1,module2,...,moduleN This does the opposite of above. Only the modules listed are autodetected. This can limit the sometimes lengthy autodetection sequence to just the installation bootup, After which, bootup should be as fast as a custom compiled kernel. The intent is clearly to reduce, and perhaps someday eliminate, the need for most people to compile the kernel. Another benefit is that autodetection causes some machines to lockup at boottime. This provides a dynamic way to selectively disable modules. DMA MEMORY ISSUES: ------------------ One undesirable feature of current Linux device drivers is that they are allowed to do memory math at init time to allocate themselves some memory. For a few devices (basically only the sound and qic02tape), they require memory that has the same physical and logical address for DMA. The rest can just use the normal memory allocation of the kernel. To this end I have changed all devices to use a dalloc() call instead of memory math. These currently provide roughly the same functionality as the current kernel, but allow for all devices to be loadable as modules. There is also a dmamalloc() call for Tape and Sound, as there has to be a block of contiguous memory to allocate for the device when it is loaded. To control this behaviour, you can use the "mod=" option, whose syntax is: linux mod=DMA,NUM,debug DMA is the amount of dma ram to set aside, NUM is the number of modules you wish to load after boottime before ram is released, and debug gives a verbose printout of the sequence of module initialization. The following statement at the lilo prompt, sets aside the specified amount of memory for boot load modules (from the default of about 256K). linux mod=512 This reserves 512K of ram for modules at boottime. Again, the memory is called dma memory because this type of memory allocation is the only kind that can be used for dma (memory_start math). kmalloc will not work. Normally, any unused portion of the above memory is released by the time init is called, right after bootup. However, if one wishes to load the qic02tape driver or the sound driver after bootup (the only option without recompiling as they are not part of the default kernel), an additional step is required: linux mod=-1,1 This tells the kernel to not release the unused dma memory after bootup but instead allow you to load '1' module before releasing unsed ram. If you want the tape driver as well, and allow for extra ram you would use: linux mod=600,2 etc. Note: DMA requiring modules must then be the FIRST modules loaded after booting. While the preceding may seem somewhat contrived, there may not be a general solution to the problem of allocating a chunk of DMA ram at any arbitrary time without a reboot. Of course, I would be delighted to be proved wrong, but until then, if you need these devices, the best way may be to compile them into the kernel. USING IT: --------- Normally to use a module you "insmod" it. To have it done at boottime for you automatically, you just move or copy it into /install/modules. If you still want to rebuild the kernel, you will need to ensure that you have installed the accompanying module utilities: insmod, rmmod and lsmod. Do a make config as usual, but type 'm' for to bootload a module, or 'l' to have it compiled but not loaded. Then do a 'make dep' as usual. Then type "make mImage". This will make "mImage" which you can boot exactly the same as zImage. After booting, do "lsmod" to see the loaded modules. In later builds, you can control exactly which modules are loaded into the bootstrap, by editing .config, and thus avoid the lengthy make config. Normal builds without modules are supported as usual. FUTURES: -------- The sound code, although loadable, needs to be modified to allow loading individual low-level (board) drivers. Since it also has DMA complications, this was not done for SLS. Sound can really only be loaded at boottime, or by using the "mod=" lilo option, because it needs 1:1 mapped memory for dma. The console, keyboard and serial code (and ipc?) could also be made loadable. Payback is minimal, unless Linux is used in imbedded systems. Better detection of when modules are busy, and hence unloadable, should also be added. A (much) better configuration control mechanism should be put in place. Better memory management could be used, say removing the restriction of aligning modules on page boundaries. In a typical non-SCSI installation of about 10 modules, this could save about 20K (assuming 1/2 page per module). For the bootstrap-loader, rather than add linker logic code to the kernel, the fixup has been done at compile time (using a modified insmod.c from the module package). Perhaps in later implementations this will change, because modules this causes modules to be bigger at boottime. It might be necessary to save room in the boot image as the kernel and or disk modules continues to grow. Future implementations might include auto loading of devices upon open (demand loading) and unloading when idle. The option to install on an existing partition is really designed to allow installation on systems with a big partition HOW TO MODULARIZE A DRIVER: --------------------------- The first requirement to make module foo.o a module, is that it have two functions foo_init() and foo_cleanup(). There must also be the following: #include <linux/module.h> char foo_version[] = UTS_RELEASE; Finally, memory allocation should not use memory math on mem_start, but should rather use dmalloc() etc, as defined in module.c. Simple huh. Oh, and if you want to pass arguments at init time. there should also be a foo_setup(). Using "insmod -a N module.o" will pass argument N to the module. Currently, only integers are supported. Lastly, if you get an undefined symbol when trying to load a module, it means that you need to add it to kernel/ksyms.S. MESH: ----- Mesh, the Softlanding MEnu SHell, is a cross between a menu system, a file browser and a (somewhat bash-like) shell. It is also designed to serve as the front end to a system administration program, under development. Mesh is designed to reduce the number of keystrokes and be easy to learn. Any normal unix command can be executed from the mesh command line. The current file name can also be referenced by the first %s in the command line. The second %s refers to the destination (other) window, and the third %s, the current window. Additionally, Mesh displays menu items at the bottom of the screen, which can be selected using the Alt-X command, where X is substituted with the first capital letter in the menu title string. Mesh also has popup lists which can be cursored through, or shortcutted by just typing the letter that is capitalized in the label. Mesh doesn't actually have any built in menu items. Rather menus are defined in /etc/meshrc, ~/.meshrc, and/or are specified with the -menu argument. At any time, you can use Alt-Z to return to the top level menu. Other behaviour of note includes: When you just hit enter at a file, the default action is executed. The default action is based upon the file suffix as defined by the Suffix settings in .meshrc. Note that if no extension is matched, the last defined Suffix entry gets used, usually the program "less". When you hit enter the first match is executed. Or, Typing just the command '1' causes it to skip the first match. '2' skips the first 2 matches etc. Note that control-k is considered a shortcut for '1', or skip 1. In all cases, failure to match causes the last or default Suffix command to be executed. Additionally, if a file is executable, and it has no extension matching default rule, then you can execute it with control-k. You can see what suffix defaults the current file matches using the .Setup.Keys command. Powerful as it is, Mesh is soon to be overhauled to use Tcl, for greater flexibility, configurability, and generality. MAN PAGES: ---------- The change of direction of not preformatting the man pages has come about primarily for two reasons. First and foremost, Tkman an X based manual page reader that now comes with SLS requires unformatted pages to work properly. This reader which offers hypertext, section parsing, history and much more makes reading man pages a real joy compared to the old more or less approach. It would also be nice to see a text based version of this reader RSN. Secondly, numerous people pointed out that trying to print preformatted man pages caused most printers to complain (well barf actually). And even if you got it to work, it looked lousy. All you got was typewriter font, and all the page numbers didn't line up on page boundries, etc, etc. Anyways, formatting usually takes only a second or two on most machines. BUGS/WARNINGS: -------------- Unloading modules is currently not guarrented to clean up everything properly for all devices. Individual drivers need perhaps more attention. The source to picasso has been included because it has a fair bit of C++ code, and because there is a bug under Linux/Tk with image rotate and stretch. The compiler must be installed in order to use X-windows, in order to link the X servers. This saves around 3 Meg in the distribution. The option to install on an existing partition is really designed to allow installation on systems with a big partition containing data (like /home) that should be preserved. AVAILABILITY: ------------- SLS is available on floppies (31 5.25 floppies or 26 3.5 floppies), QIC150 or CDROM from the address below for a flat rate distribution fee of US $99 ($125 Canadian) + $15 shipping and handling. Mail payment, either cheque or money order, in advance, to Softlanding. Visa and Mastercard are also accepted. The SLS CDROM contains the full source tree and a 60+ page user manual "Using SLS". A quarterly CD (4 CD's over 1 year) is available for US $199 (255 Canadian) + $15 S&H. Quantity discounts are also available for resellers. When ordering floppies, ensure that you specify the bootdisk type (3 1/2 or 5 1/4). Softlanding also offers support subscriptions for SLS as follows: Individual support, (one user, one machine) is $99 per year. Group support, primarily for resellers and reseller/corporate, $999 per Softlanding Software PO Box 48054 - 3575 Douglas St, Victoria, BC, Canada V8Z-7HS Phone (604) 592-0188 FAX (604) 595-5820 See Softlanding for a gentle touch down from a DOS bailout.